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iFolder 3.9.2 Security Administration Guide 


About This Guide 


This guide provides specific instructions on how to install, configure, and maintain ¡Folder server and 
¡Folder clients in the most secure way possible. 


¢ Chapter 1, “Security Best Practices Overview,” on page 7 

+ Chapter 2, “Security Best Practices for iFolder,” on page 9 

+ Chapter 3, “Security Best Practices for the ¡Folder Client,” on page 15 
¢ Chapter 4, “Other Security Best Practices,” on page 17 

+ Appendix A, “Documentation Updates,” on page 19 


Audience 


This guide is intended for network security administrators. 


Feedback 


We want to hear your comments and suggestions about this manual and the other documentation 
included with this product. Please use the User Comment feature at the bottom of each page of the 
online documentation. 


Documentation Updates 


For the most recent version of the ¡Folder 3.x Security Administrator Guide, visit the Novell ¡Folder 3.x 
documentation Web site (http://www.novell.com/documentation/ifolder3/). 


For emerging issues with ¡Folder server and client, see the Novell ¡Folder 3.9.2 Readme (http:// 
www.novell.com/documentation/ifolder3/index.html). 


Additional Documentation 


+ Novell iFolder 3.x documentation (http://www.novell.com/documentation/ifolder3/index.html) 
+ Novell Technical Support (http://www.novell.com/support/) 


When a single pathname can be written with a backslash for some platforms or a forward slash for 
other platforms, the pathname is presented with a backslash. Users of platforms that require a 
forward slash, such as Linux or UNIX, should use forward slashes as required by your software. 
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1 Security Best Practices Overview 


1,1 


This section summarizes the recommended configurations and settings required to run Micro Focus 


¡Folder server and the ¡Folder clients in a secure mode. 


¢ Section 1.1, “Security Recommendations for iFolder,” on page 7 


Security Recommendations for ¡Folder 


The following table lists the ¡Folder server configuration settings that impact ¡Folder security. 


Table 1-1 Security Recommendations 


Parameter 


¡Folder Admin user 


Equivalent ¡Folder 
Admin users 


¡Folder Proxy user 
password 


Server to client 
communications 


Server to Server 
Communication 


/usr/web/web.config 
file 


Possible Values 


User-specified 


User-specified 


User-specified 


SimiasRequireSSL (Yes/ 
No) 


Select Yes during setup 
to enable SSL, or select 
No to disable SSL 


SimiasUrl (https/http) 


SimiasCert (RAW 
certificate/none) 


Default Value 


User-specified 
administrator user 


None 


Auto generated during 
initial configuration of the 
iFolder server 


SimiasRequireSSL = 
Yes 


Yes, SSL enabled 
SimiasUrl https 


SimiasCert <RAW 
certificate> 


SimiasRequireSSL https 


SimiasCert <RAW 
certificate> 


Recommended Value 
for Best Security 


Special iFolder Admin 
user identity for 
managing iFolder 
services 


Users with limited 
administrator rights, 
such as for a specific 
iFolder server 


User-specified, using 
strong password 
practices 


SimiasRequireSSL = 
Yes 


Yes, SSL enabled 


SimiasRequireSSL https 


SimiasCert <RAW 
certificate> 
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2 Security Best Practices for iFolder 


2.1 


2.1.1 


This section provides specific instructions on how to install, configure, and maintain iFolder in the 
most secure way possible. 
+ Section 2.1, “Secure Communication with the LDAP Server,” on page 9 


+ Section 2.2, “Communication between the Web Admin Server and the Web Admin Browser,” on 
page 10 


+ Section 2.3, “Enterprise Client/Server Communications,” on page 10 

+ Section 2.4, “Web Access Server Communications,” on page 10 

¢ Section 2.5, “Disabling the SSL 2.0 Protocol,” on page 10 

+ Section 2.6, “Configuring a Cipher Suite to Use for SSL/TLS,” on page 10 

+ Section 2.7, “Installing Trusted Roots and Certifications on the iFolder Server,” on page 11 
¢ Section 2.8, “Installing Server Certificates from a Known Certificate Authority,” on page 11 
+ Section 2.9, “Using a Shared Certificate in ¡Folder Clusters,” on page 11 

¢ Section 2.10, “Ensuring Privilege Separation for the iFolder Proxy User,” on page 11 

+ Section 2.11, “Using Synchronize Now to Remove Users,” on page 12 

+ Section 2.12, “Controlling Access to the ¡Folder Data Store,” on page 12 

¢ Section 2.13, “Controlling Access to the iFolder Server Configuration Files,” on page 12 

+ Section 2.14, “Controlling Access to And Backing Up the iFolder Audit Logs,” on page 12 
¢ Section 2.15, “Encrypting Data on the Server,” on page 12 

¢ Section 2.16, “Preventing the Propagation of Viruses,” on page 13 

+ Section 2.17, “Backing Up the ¡Folder Server,” on page 13 

+ Section 2.18, “Loading the Recovery Agent Certificates,” on page 13 


Secure Communication with the LDAP Server 


¢ Section 2.1.1, “Using SSL for Server Communications,” on page 9 


Using SSL for Server Communications 


By default, the ¡Folder enterprise server is configured to communicate with the LDAP server via SSL. 
For most deployments, this setting should not be changed. If the LDAP server co-exists on the same 
server as the ¡Folder enterprise server, you can reconfigure to disable SSL, which increases the 
performance of LDAP authentications. 


For information, see “Configuring the iFolder Enterprise Server” in the Novell ¡Folder 3.9.2 
Administration Guide. 
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2.2 


2.3 


2.4 


2.9 


2.6 


Communication between the Web Admin Server 
and the Web Admin Browser 


By default, the iFolder Web Admin uses SSL for communications to the iFolder enterprise server 
being managed. For most deployments, this setting should not be changed. If the Web Admin service 
and the iFolder enterprise service are on the same server, SSL is not required. For HTTP 
connections, the password is passed in the clear. 


Enterprise Client/Server Communications 


By default, the iFolder enterprise server is configured for shared iFolder access. Client/Server 
communication is not through SSL. All data is sent to the server in the clear. For most deployments, 
this setting is used for high performance. This setting can be changed during the simias-server-setup 
configuration for iFolder. 


If you disable SSL for client/server communications, you should use a VPN (virtual private network) 
for communications over wireless networks and outside the firewall. For information, see Section 4.3, 
“Securing Communications with a VPN If SSL Is Disabled,” on page 17. 


Web Access Server Communications 


By default, the iFolder Web Access server is configured to require SSL. All Web-browser-based 
communication to the Web Access server is encrypted by using the SSL protocol. In most 
deployments, this setting should not be changed because iFolder uses Forms-based authentication 
for browser communications, which means passwords are sent to the server in the clear. For 
information, see “Configuring the Web Access Server for SSL Communications with Web Browsers” 
in the Novell iFolder 3.9.2 Administration Guide. 


Disabling the SSL 2.0 Protocol 


The built-in protections of SSL 3.0 for version rollback attacks (where the session is rolled back to 
SSL 2.0 even when both client and server support SSL 3.0) are not effective against a version 
rollback attackers who can brute force the key and substitute a new ENCRYPTED-KEY-DATA message 
containing the same key (but with normal padding) before the application specified wait threshold has 
expired. You can disable SSL 2.0 on the server, so it is not possible to establish a session using SSL 
2.0, and so version rollback attacks are not be possible. 


For information about disabling the SSL 2.0 protocol for the Apache server, see “Configuring the SSL 
Cipher Suites and Protocol for the Apache Server” in the Novell iFolder 3.9.2 Administration Guide. 


For information about configuring strong SSL/TLS security solutions, see SSL/TLS Strong 
Encryption: How-To (http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html) on the Apache.org Web 
site. 


Configuring a Cipher Suite to Use for SSLITLS 


To ensure strong encryption, we strongly recommend the following configuration for the Apache 
server’s SSL cipher suite settings: 


+ Use only High and Medium security cipher suites, such as RC4 and RSA. 
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2.8 


2.9 


2.10 


+ Remove from consideration any ciphers that do not authenticate, such as Anonymous Diffie- 
Hellman (ADH) ciphers. 


+ Disable the Low, Export, and Null cipher suites unless you need them for other applications. 


Do not disable the Low and Export cipher suites if they are required by your customer base. 
Individuals using older browsers (4-5 years old) and older versions of Windows, such as 
Windows 98 might still need those cipher suites for other services. 


For information, see “Configuring the SSL Cipher Suites for the Apache Server” in the Novell ¡Folder 
3.9.2 Administration Guide. 


For information about configuring strong SSL/TLS security solutions, see SSL/TLS Strong 
Encryption: How-To (http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html) on the Apache.org Web 
site. 


Installing Trusted Roots and Certifications on the 
¡Folder Server 


You can manually install the trusted roots and the directory public key out-of-band. For information, 
see “Managing SSL Certificates for Apache” in the Novell iFolder 3.9.2 Administration Guide. 


Installing Server Certificates from a Known 
Certificate Authority 


You should use valid certificates for both the Apache server and for communication between the 
Simias server and the Simias client daemon. Simias is the technology underpinning your iFolder 
server and client software. You should have the server public key signed by a known certificate 

authority (CA). For information, see “Generating an SSL Certificate for the Server” in the Novell 
iFolder 3.9.2 Administration Guide. 


Using a Shared Certificate in iFolder Clusters 


For a cluster where all of the nodes are acting like the same machine when they are taking their turn 
hosting, the user should have a single certificate for the highly available IP address that all of the 
nodes in the cluster share. For information, see “Configuring Apache to Point to an SSL Certificate on 
an iFolder Server” in the Novell iFolder 3.9.2 Administration Guide. 


Ensuring Privilege Separation for the iFolder 
Proxy User 


The iFolder Proxy user is a proxy user identity used to access the LDAP server to retrieve a list of 
authorized users. The proxy user is automatically created during the iFolder enterprise server 
configuration. The username is predetermined (hard-coded) on the system. For most deployments, 
this username should never change. 


Make sure that the user account assigned as the iFolder Proxy user is different than the one used for 
the iFolder Admin user and other system users. Separating the proxy user from the administrator 
provides privilege separation. 
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2.12 


2.13 


2.14 


2.15 


The proxy user password is auto-generated and stored briefly in the /<data path>/simias/ 
.simias.ppf file of the ¡Folder server. This file is created during the configuration of the ¡Folder 
enterprise server and is removed when the server starts for the first time. A restart of Apache is forced 
at the end of the configuration process, which in turn starts the ¡Folder service. During the initial 
startup, the ¡Folder process reads the file, stores and encrypts the password by using the public key 
of the ¡Folder server in the server's Simias database, and then removes the password from the file. 


Using Synchronize Now to Remove Users 


The ¡Folder user or group list is periodically updated based on the LDAP synchronization interval. 
Whenever you remove users or groups from a LDAP Search DN, or remove contexts from the Search 
DN list, you should synchronize the list immediately using the Synchronize now option in the server 
details page in the Web ¡Folder Admin to enforce your changes. 


Controlling Access to the ¡Folder Data Store 


By default, the iFolder server stores the database and user files under the /<data path>/simias 
directory. The Apache Server user wwwrun by default owns those files. You must use every 
precaution to avoid inadvertently assign rights to unauthorized users. 


Controlling Access to the ¡Folder Server 
Configuration Files 


The ¡Folder server stores the configuration files in the /<data path>/simias directory. The Apache 
Server user wwwrun owns the configuration file. You must use every precaution to avoid inadvertently 
assigning rights to unauthorized users. 


Controlling Access to And Backing Up the ¡Folder 
Audit Logs 


By default, the ¡Folder server stores the audit logs in the /<data path>/simias/logs directory. The 
¡Folder server administrator should guarantee that rights are not inadvertently assigned to 
unauthorized users. Administrators should also periodically back up the rolled-over logs in case they 
are ever needed for forensic purposes. Audit logs should be monitored periodically. 


For information, see “Managing the Simias Log and Simias Access Log” in the Novell ¡Folder 3.9.2 
Administration Guide. 


Encrypting Data on the Server 


¡Folder uses Blowfish to encrypt the data on the wire. The data is then encrypted and stored on the 
enterprise server. This is same as in ¡Folder 2.x, which provides passphrase-based encryption. To 
enable encryption for the users, set the encryption policy to On under the System policy in the Web 
Admin console. 


For more information, see “Configuring System Policies” in the Novell ¡Folder 3.9.2 Administration 
Guide. 
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2.16 


2.17 


2.18 


Preventing the Propagation of Viruses 


Because ¡Folder is a cross-platform distributed solution, there is a possibility of a virus infection on 
one platform migrating across the ¡Folder server to other platforms, and vice versa. You should 
enforce server-based virus scanning to prevent viruses from entering the corporate network. 


You should also enforce client-based virus scanning. 


Backing Up the ¡Folder Server 


Backing up the ¡Folder user data and configuration data should be done regularly. The backup media 
should be stored in a secure offsite facility. 


During backup and restore, the ¡Folder data itself is not encrypted. If the ¡Folder store and the backup 
media are on different computers, use SSL to transfer data between the computers. It is not 
necessary to use SSL if the iFolder store and backup media are on the same computer. 


For information, see the following in the Novell iFolder 3.9.2 Administration Guide: 


+ “Backing Up the ¡Folder Server” 
¢ “Recovering from a Catastrophic Loss of the ¡Folder Server” 
+ “Recovering iFolder Data from File System Backup” 
For sensitive data, use one of the following methods to encrypt the data backup: 
+ Encrypt the data itself if the application that creates the data supports encryption. For example, 
database products and third-party tools support data encryption. 


+ Use backup software that is able to encrypt data as you back it up. This method has 
performance and manageability challenges, especially for managing encryption keys. 


+ Use an encryption appliance that encrypts sensitive backup media as data is backed up. 
If you transport and store media offsite, use a company that specializes in media shipment and 


storage. This way, your tapes are tracked via bar codes, stored in environmentally friendly conditions, 
and are handled by a company whose reputation rests on its ability to handle your media properly. 


Loading the Recovery Agent Certificates 


The iFolder service by default is not configured for the Recovery agent. During server configuration, 
ensure that the Recovery agent path is configured. This path should contain the list of certificates that 
the service can load for the users to select from. For more information on loading the Recovery agent 
certificates, see “Recovery Agent Certificates ” in the Novell iFolder 3.9.2 Administration Guide. 
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3.1 


3.2 


Security Best Practices for the ¡Folder 
Client 


This section provides specific instructions on how to install, configure, and maintain the ¡Folder client 
in the most secure way possible. 

¢ Section 3.1, “Configuring Client-Side Firewalls for ¡Folder Communications,” on page 15 

¢ Section 3.2, “Configuring Client-Side Virus Scanners for ¡Folder Communications,” on page 15 

¢ Section 3.3, “Configuring a Web Browser to Use SSL 3.0,” on page 15 

+ Section 3.4, “Creating an Encrypted iFolder,” on page 16 

+ Section 3.5, “Using the Recovery Agent,” on page 16 

+ Section 3.6, “Transferring the Encryption Key,” on page 16 


Configuring Client-Side Firewalls for iFolder 
Communications 


If users deploy a client-side firewall, they must set the firewall to allow the iFolder client to 
communicate locally (on the same computer) with Mono XSP Server. iFolder communicates to Mono 
XSP Web services, which communicates, in turn, with the iFolder enterprise server via HTTP BASIC 
or SSL, as governed by the system settings for the iFolder enterprise server. The user can allow 
iFolder to choose a local dynamic port for local iFolder traffic, or configure a local static port for 
iFolder to use for that purpose. 


Configuring Client-Side Virus Scanners for iFolder 
Communications 


Because iFolder is a cross-platform distributed solution, there is a possibility of a virus infection on 
one platform migrating across the iFolder server to other platforms, and vice versa. You should 
enforce client-based virus scanning to prevent viruses from entering the corporate network. 


Scanning the ..\simias\WorkArea\ directory for viruses causes problems with synchronization if a 
virus is detected on download. The . .\simias\WorkArea\ directory is where ¡Folder stages files for 
download from the server. Users should set their virus scanners to avoid scanning the 
..\simias\WorkArea directory. Scanners can detect the virus when ¡Folder moves the infected file 
from the staging area to the target iFolder. 


Configuring a Web Browser to Use SSL 3.0 


iFolder servers expect users to connect to the enterprise server account and the Web access server 
with SSL 3.0 connections. Both the client and browser connections use the browser’s settings for 
SSL. If Microsoft IE is installed on your system, the iFolder client uses those settings over any other 
browser configuration for the client. Make sure the IE browser settings and other browsers you use to 
connect to iFolder servers are configured to use SSL 3.0. 


Security Best Practices for the iFolder Client 15 


16 


3.4 


3.5 


3.6 


Creating an Encrypted iFolder 


iFolder supports encrypted iFolder storage. To store the files encrypted, users must ensure that the 
iFolder they are uploading to is created as encrypted. For that, they must ensure that the option for 
Encryption is selected. They also must specify a passphrase and select a Recovery agent when 
creating an encrypted iFolder by using the iFolder thick client. However, this option is available only 
when you set the Encryption policy to On. In this case, users are free to choose between the two 
options: Regular and Encrypted. However, if you set the encryption policy to Enforced, users can 
create only encrypted iFolders and they cannot change this encryption settings for their iFolders. 


NOTE: Even if the encryption policy is set to Enforced, you can create a regular ¡Folder by using the 
Create button on the iFolder page of the iFolder Web Admin console. 


An existing iFolder cannot be converted to be an encrypted iFolder, and an encrypted iFolder cannot 
be converted to be a regular iFolder. 


During the creation of an encrypted iFolder, the user is prompted to enter a passphrase and select a 
Recovery agent. iFolder uses the passphrase to dynamically generate a unique encryption key for 
encrypting and decrypting the key used for data encryption. The encrypted iFolders are not 
processed without the passphrase. If the user forgets the secret passphrase, he or she cannot 
access either the iFolder data or the encrypted key used for recovering it. In this case, the Recovery 
agent that is selected when the passphrase is set helps in recovering the encryption key. For more 
information on the Recovery agent, see the Section 3.5, “Using the Recovery Agent,” on page 16. 


Using the Recovery Agent 


The iFolder enterprise server uses a Recovery agent, which is an X.509 certificate-based entity used 
to recover a lost or otherwise unavailable key for encrypted iFolders. 


iFolder prompts a user to select a Recovery agent from a list when the user specifies the passphrase 
for an encrypted iFolder. However, this option is available only if you set encryption policy to On by 
using the Web Admin console. When the user has lost or forgotten the passphrase, the Recovery 
agent helps the user to recover the data.The user exports the encrypted key and sends it to the 
Recovery agent by using the Key Recovery option available under the Security menu in the client. 
After receiving the encrypted key, the Recovery agent decrypts it by using its private key, and sends it 
back to the iFolder user. The user then imports the decrypted key and then resets the passphrase by 
using the Security menu in the client. 


Transferring the Encryption Key 


The Recovery agent can encrypt the decrypted keys using a one time passphrase (OTP), then it 
sends both the encrypted passphrase and the key to the user. For secure OTP transfer, make sure 
that the Recovery agent uses an out-of-band communication or a separate e-mail communication to 
send the passphrase and the key to the user. 


All the keys are Base 4 encoded for easier data exchange. The key is highly vulnerable during 
transfer if it is not encrypted with the OTP. 
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4.2 


4.3 


Other Security Best Practices 


This section discusses other security best practices for your iFolder servers and resources. 


¢ Section 4.1, “Controlling Physical Access to the ¡Folder Servers and Resources,” on page 17 
¢ Section 4.2, “Securing Access to the Servers with a Firewall,” on page 17 

¢ Section 4.3, “Securing Communications with a VPN If SSL Is Disabled,” on page 17 

¢ Section 4.4, “Securing Wireless LAN Connections If SSL Is Disabled,” on page 18 


¢ Section 4.5, “Creating Strong Password And Passphrase,” on page 18 


Controlling Physical Access to the ¡Folder Servers 
and Resources 


+ Servers must be kept in a physically secure location with access by authorized personnel only. 
+ The corporate network must be physically secured against eavesdropping or packet sniffing. 


Securing Access to the Servers with a Firewall 


If the ¡Folder enterprise server, Web Admin server or Web Access server is accessible from outside 
the corporate network, a firewall should be employed to prevent direct access by a would-be intruder. 


Securing Communications with a VPN If SSL Is 
Disabled 


We recommend configuring ¡Folder to use encryption for all data exchanges between its different 
components because ¡Folder data is not encrypted by default. If you configure ¡Folder not to use 
encryption between the enterprise server and client or between the Web access server and the user's 
Web browser, the user data is susceptible to eavesdropping or packet sniffing by third parties outside 
the corporate firewall. 


Even if you consider the corporate environment to be a trusted environment, a VPN (virtual private 
network) should be employed for server-client and server-browser connections in the following 
situations: 


+ When the users access the servers from outside of the corporate firewall 


+ When the users access the servers across a wireless network. Wireless access points and 
adapters broadcast data into space, where the signals can be intercepted by anyone with the 
ability to listen in at the appropriate frequency. 


For accessing the Web Access server over a VPN, make sure to disable split tunneling so that the 
traffic goes through the VPN connection to the corporate network, not over the public Internet. 
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For information about configuring SSL features for these communications, see the following: 


+ 


+ 


Section 2.3, “Enterprise Client/Server Communications,” on page 10 
Section 2.4, “Web Access Server Communications,” on page 10 


4.4 Securing Wireless LAN Connections If SSL Is 
Disabled 


Protecting a wireless network requires forethought and planning, just as protecting a wired network 
does. Among the key protective measures to be undertaken are: 


+ 


Enable WEP (Wired Equivalent Privacy) encryption, but do not rely on WEP alone to provide 
security for the wireless network. Use other typical LAN security mechanisms such as VPNs, 
firewalls, and authentication to ensure privacy. For information, see Section 4.3, “Securing 
Communications with a VPN If SSL Is Disabled,” on page 17. 


Survey the interference and jamming likelihood for a planned wireless LAN before it is installed. 


Change the default manufacturer’s password for your wireless access points, gateways, or 
routers. 


Limit, as much as is possible, who can attach to a wireless network. For example, using MAC 
address filtering is practical for small networks, but it is a time-consuming administrative effort for 
large networks. 


Use an anonymous Service Set Identifier (SSID) by turning off the SSID broadcast for access 
points. 


4.5 Creating Strong Password And Passphrase 


Make sure to employ security best practices for passwords, such as the following: 


+ 


Length: The minimum recommended length is 6 characters. A secure password is at least 8 
characters; longer passwords are better. 


Complexity: A secure password contains a mixture of letters and numbers. It should contain 
both uppercase and lowercase letters and at least one numeric character. Adding numbers to 
passwords, especially when they are added to the middle and not just at the beginning or the 
end, can enhance password strength. Special characters such as &, $, and > can greatly improve 
the strength of a password. 


Do not use recognizable words, such as proper names or words from a dictionary, even if they 
are bookended with numbers. Do not use personal information, such as phone numbers, birth 
dates, anniversary dates, addresses, or ZIP codes. Do not invert recognizable information; 
inverting bad passwords does not make them more secure. 


Uniqueness: Do not use the same passwords for all servers. Make sure to use separate 
passwords for each server so that if one server is compromised, all of your servers are not 
immediately at risk. 
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A Documentation Updates 


A.1 


A.2 


A.3 


A.4 


This section contains information about documentation content changes made to the ¡Folder 3.x 
Security Administrator Guide since the initial release of ¡Folder 3.x. If you are an existing user, review 
the change entries to readily identify modified content. If you are a new user, simply read the guide in 
its current state. 


Refer to the publication date, which appears on the title page and the Legal Notices page, to 
determine the release date of this guide. For the most recent version of the ¡Folder 3.x Security 
Administrator Guide, see the Novell ¡Folder 3.x documentation Web site (http: //www.novell.com/ 
documentation/ifolder3/). 


In this section, content changes appear in reverse chronological order, according to the publication 

date. Within a dated entry, changes are grouped and sequenced, according to where they appear in 
the document itself. Each change entry provides a link to the related topic and a brief description of 
the change. 


This document was updated on the following dates: 


+ Section A.1, “August 2015,” on page 19 

¢ Section A.2, “January 2014,” on page 19 

+ Section A.3, “December 2008,” on page 19 

+ Section A.4, “December 2007,” on page 20 

¢ Section A.5, “October 2007,” on page 20 

+ Section A.6, “August 15, 2006,” on page 21 

¢ Section A.7, “November 1, 2005,” on page 21 


June 2016 


This guide was updated to support the OES 2015 SP1 release. 


August 2015 


This guide was updated to support the OES 2015 release. 


January 2014 


This guide was updated to support the OES 11 SP2 release. 


December 2008 


The following sections were added or changed: 
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A.5 


A.6 


Location 


Section 1.1, “Security 
Recommendations for 
iFolder,” on page 7 


Section 2.10, “Ensuring 
Privilege Separation for the 
¡Folder Proxy User,” on 
page 11 


Section 2.11, “Using 
Synchronize Now to 
Remove Users,” on page 12 


Section 3.5, “Using the 
Recovery Agent,” on 
page 16 


Change 


Updated Table 1-1 on page 7 with new entries for server-to-server 
communication and Web config file. 


Updated the default path to the ¡Folder proxy user password. 


Updated to include the details about ¡Folder Groups. 


Modified the GUI reference for all shared or normal ¡Folder to Regular 
iFolder. 


December 2007 


Made editorial changes and revisions. The content is unchanged. 


October 2007 


The following sections were added or changed: 


Location 


Section 2.3, “Enterprise 
Client/Server 
Communications,” on 
page 10 


Section 2.12, “Controlling 
Access to the iFolder Data 
Store,” on page 12 


Section 2.13, “Controlling 
Access to the iFolder Server 
Configuration Files,” on 
page 12 


Section 2.14, “Controlling 
Access to And Backing Up 
the iFolder Audit Logs,” on 
page 12 


Section 2.18, “Loading the 
Recovery Agent 
Certificates,” on page 13 


Section 3.4, “Creating an 
Encrypted iFolder,” on 
page 16 


Change 


All data are also sent to the server in the clear. For most deployments, this 
setting is maintained for performance. Currently, this setting cannot be 
changed. 


Updated the section to include the new path to the simias directory, where 
the iFolder server stores the database and user files. 


Updated the default path to the iFolder configuration files. 


Updated the default path to the iFolder audit logs. 


The iFolder service by default is not configured for the Recovery agent. 
During server configuration, ensure that the Recovery agent path is 
configured. 


The iFolder 3.6 server supports encrypted iFolder storage. To store the 
files encrypted, the user must ensure that the iFolder is created encrypted 
before uploading the files. 
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A.8 


Location Change 


Section 3.5, “Using the The ¡Folder 3.6 enterprise server uses a Recovery agent, which is an 
Recovery Agent,” on X.509 certificate-based entity used to recover a lost or otherwise 

page 16 unavailable key. 

Section 3.6, “Transferring For secure OTP transfer, make sure that the Recovery agent uses an out- 
the Encryption Key,” on of-band communication or a separate e-mail communication to send the 
page 16 passphrase and the key to the user. 


August 15, 2006 


The following change was made to this section: 


Location Change 
Section 2.6, “Configuring a Do not disable the Low and Export cipher suites if they are required by 
Cipher Suite to Use for SSL/ your customer base. Individuals using older browsers (4-5 years old) and 


TLS,” on page 10 older versions of Windows, such as Windows 98, might still need those 
cipher suites for other services. 


November 1, 2005 


The entire guide was reformatted to comply with revised documentation standards. The content is 
unchanged. 
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